Add ERC: Contract Feature Detection #1146
Conversation
|
The commit 879f6a5 (as a parent of fa0d0ff) contains errors. |
|
This is a good idea. Could the spec additionally implement some sort of feature discoverability method like |
|
An implementation of 7996 could provide that but the minimal implementation is just a single feature getter. |
uppercase Co-authored-by: Mercy Boma Naps Nkari <[email protected]>
ERCS/erc-7996.md
Outdated
|
|
||
| ## Abstract | ||
|
|
||
| Creates a standard method to publish and detect what features a smart contract implements that lack an [ERC-165](./eip-165.md) interface. |
There was a problem hiding this comment.
Your abstract is lacking a bit of technical meat. You should describe, at a high level, what the "standard method" actually is.
There was a problem hiding this comment.
I added a few more words, let me know if that is sufficient.
For reference, I was following the ERC-165 specification, but I guess that was written a while ago.
ERCS/erc-7996.md
Outdated
|
|
||
| ## Rationale | ||
|
|
||
| Defining a new standard avoids unnecessary pollution of the ERC-165 selector namespace with synthetic interfaces representing features. |
There was a problem hiding this comment.
The rationale section should explain choices made within the document, not why we need the entire standard. For example, you could explain why you've chosen reverse domain names as the feature names.
There was a problem hiding this comment.
I moved this sentence to the motivation section.
I added a new sentence that describes why a reverse domain name.
6 participants
Uh oh!
There was an error while loading. Please reload this page.